feat(sol): frontier provider mesh with proof-carrying execution - #264
Draft
Deleted user (ghost) wants to merge 104 commits into
Draft
feat(sol): frontier provider mesh with proof-carrying execution#264Deleted user (ghost) wants to merge 104 commits into
Deleted user (ghost) wants to merge 104 commits into
Conversation
added 30 commits
August 14, 2026 19:23
Member
|
Exact-head dependency triage for current PR #264 head The 7 findings are confined to the dev/tooling graph. Direct findings: |
This was referenced Aug 19, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Purpose
Continue the SOL control plane into a provider-neutral frontier interoperability mesh while keeping Automaton-3 as the sole authority root, and add a durable cross-provider organization loop in which provider work becomes bounded, content-addressed, non-authoritative evidence instead of disappearing in chat/session state.
Exact lineage attestation
#225is restored to its frozen headcd920379.... A transient placement error put the organism commits on the #225 head branch; the exact 24-file implementation delta was transplanted as one commit on #264 (31aec51c... -> ec84aa32...) and #225 was then restored byte-exact tocd920379.... The current #264 head adds one CI repair commit over that integration so LUT-KAN direct execution has repository-root import visibility.Integrated external exact-head witness — ESTABLISHED
A separate GitHub-hosted runner checked out AEGIS by exact SHA
5f331e55d5d3a3f14c99d800eefaa13178cc098eand ran the inherited Frontier/Sensorium verification and the new cross-provider organism path in one job.Observed execution:
The real provider stdio cycle is:
The provider contribution remains
NON_AUTHORITATIVE_EVIDENCE; it cannot approve, verify or admit itself.Durable organism implementation
The integrated slice includes:
WAITING_OPERATORsemantics and explicit approval path;Provider-session bootstrap produces identity only:
Authority remains external to model output. The CI E2E uses a deterministic test authority key fixture solely inside the runner; this is not represented as a production-safe signer topology.
Current ledger
Constitutional Sensorium boundary
The observation contract remains non-authoritative:
Provider/model output is evidence only. D3 requires explicit operator approval and D4 remains denied. No provider win, score or contribution changes AEGIS authority.
Security/dependency boundary
The earlier #264 dependency triage established that the reported npm vulnerabilities are in the development/tooling graph while
npm audit --omit=devreported zero production-graph vulnerabilities at that audited SHA. This does not erase the tooling debt and no forced dependency upgrade is applied here.Deliberately not claimed
main;Next implementation closure
The next organism slice reuses the existing #264
SSEStreamLeaseowner/generation/fencing semantics to add durable work claim/lease fencing so multiple providers cannot silently duplicate the same queued work. This must remain bounded by the same Automaton-3 authority path rather than creating a second scheduler authority root.Effect-bound verification continues independently through the frozen
#268 -> #270 -> #272lineage; this PR does not reinterpret DecisionReceipt, ExecutionReceipt or EffectReceipt semantics.